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ABSTRACT 


This document describes operations associated with a set of flight experiments and 
demonstrations using a Boeing-757-200 research aircraft as part of low visibility landing 
and surface operations (LVLASO) research activities. To support this experiment, the B- 
757 performed flight and taxi operations at the Hartsfield- Atlanta International Airport 
(ATL) in Atlanta, GA. The test aircraft was equipped with experimental displays that were 
designed to provide flight crews with sufficient information to enable safe, expedient 
surface operations in any weather condition down to a runway visual range (RVR) of 300 
feet. In addition to flight deck displays and supporting equipment onboard the B-757, 
there was also a ground-based component of the system that provided for ground controller 
inputs and surveillance of airport surface movements. 

The integrated ground and airborne components resulted in a system that has the potential 
to significantly improve the safety and efficiency of airport surface movements particularly 
as weather conditions deteriorate. Several advanced technologies were employed to show 
the validity of the operational concept at a major airport facility, to validate flight simulation 
findings, and to assess each of the individual technologies’ performance in an airport 
environment. Results show that while the lack of maturity of some of the technologies do 
not permit immediate implementation, the operational concept is valid and the performance 
is more than adequate in many areas. Finally, over 100 visitors from the Federal Aviation 
Administration (FAA) and the aviation community attended the demonstration sessions 
toward the end of the testing phase. Their impressions are also documented here. 

REFERENCE 

This activity can be considered a follow-on to trials performed at the FAA Technical Center 
in Atlantic City, NJ during the summer of 1995 on NASA’s Boeing-737- 100 aircraft [1], 
This flight test activity builds on lessons-leamed in 1995 as well as flight simulation studies 
and a workshop [2] held in the interim. 
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I. 


INTRODUCTION 


A. FLIGHT TEST OBJECTIVES 

The purpose of this activity was to meet a Level I milestone of NASA’s Terminal Area 
Productivity (TAP) program. The TAP program is aimed at developing requirements for 
terminal area operations and technologies that will safely enable the same, or higher, 
capacity at the major airports in Visual Meteorological Conditions (VMC) and Instrument 
Meteorological Conditions (IMC). TAP research activities have been decomposed into four 
sub-elements: air traffic management, reduced separation operations, aircraft-ATC 
integration, and low visibility landing and surface operations (LVLASO). This flight 
testing was part of ongoing research under the LVLASO sub-element of TAP. 

In general, the LVLASO research is aimed at investigating technology as a means to 
improve the safety and efficiency of aircraft movements on the surface during the 
operational phases of roll-out, turnoff, inbound taxi, and outbound taxi. This investigation 
becomes critical in the face of growing demands for air travel, the increasing number of 
reported surface incidents (287 in 1996) and fatal accidents (5 since 1990), and the 
economic, environmental, and geographic infeasibility of constructing new airports and/or 
runways. The goal of this research, which began in 1993, is to investigate technology as a 
means of making better use of existing runways and ideally, enable safe VMC capacities 
(i.e. flow rates) on the surface in weather conditions down to a visibility of 300’ . 

Specifically, the objectives of this flight test were to demonstrate a prototype system that 
has the potential to meet the LVLASO goal; validate selected simulation findings and the 
operational concept at a major airport facility; and assess the performance and suitability of 
the prototype as compared to (a) die operational requirements of an Advanced Surface 
Movement Guidance and Control System (A-SMGCS) [3], as well as (b) the requirements 
of NASA’s conceptual system. 

The architecture defined for the prototype LVLASO system tested at ATL was derived from 
three constraints: do not add workload to the users of the system (i.e. pilots and 
controllers); focus on the needs of the users in IMC conditions, or at night, where 
hazardous situations are more likely and movements tend to slow down; and make every 
effort to use technologies that are either already part of the National Airspace System 
(NAS) or are planned to be in the NAS. 

B. BACKGROUND 

In order to operate safely in poor weather conditions at traffic densities equal to those 
accomplished in clear weather, both pilots and controllers must be provided with 
supplemental information about the state of the airport environment and their surroundings. 
Because many normal visual cues are not available in these conditions, this supplemental 
information should reinforce, or “fill the gaps” in missing awareness. Assuming a fully 
operational aircraft, in general, there are three information types required by the pilot to 
safely control the movement of the aircraft while avoiding an accident/incident on the 
airport surface. These are: 
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1 . Continuous awareness of position. 

2. Continuous awareness of traffic or obstacle positions that may impede progressing to 
the destination. 

3. Understanding of the path to follow from current position to the desired destination. 

In other words, “Where am I?”, “What are the hazards along the way that I should avoid?”, 
and “How do I get there from here?”. 

In the airport environment, controllers have similar needs when handling traffic on the 
surface, except they need this information for all vehicles moving on the surface. Of 
course, they also have the responsibility of providing the path, or route to follow, to all 
vehicles/aircraft on the surface movement area. 

The general requirements mentioned above are captured in greater detail in the draft 
operational requirements for A-SMGCS being considered for publication by the 
International Civil Aviation Organization (ICAO) [3], 

Currently, position awareness on the surface is determined by both pilots and controllers 
by way of visual scans of the outside scene and, to a lesser degree, radio communications 
to confirm position. In most cases, painted centerlines and markings, airfield lights, and 
signage provide adequate information to crews to safely determine position. Occasional 
reference to a paper chart may also be done to get a more “global” awareness of position, 
particularly at unfamiliar airports. Traffic and obstacles are also picked up via visual scan 
of the outside scene. The Traffic Alerting and Collision Avoidance (TCAS) system [4], 
which provides traffic information to pilots while airborne, is not currently used on the 
surface. The Airport Surface Detection Equipment (ASDE-3) radar is available at some 
airports and provides controllers with surface traffic positions on a radar screen. However, 
flight crews are not provided with this radar information. In addition, current ASDE-3 
radars do not identify or track aircraft and can report “false” targets. Finally, the path to 
follow, or route, is provided via a voice channel to the crew by the air traffic controller, 
usually a specific “ground controller”. The ground controller must maintain a mental 
picture of the routes given to all aircraft to avoid directing them into an unsafe position on 
the surface. Meanwhile, the crew must either memorize this path or write it down then 
follow the signage to the destination ramp or runway. Routes are read-back over the radio 
for confirmation by the controller. 

Based on the significant dependence on visual scans, the ability to maintain situational 
awareness as the visibility drops, or even at night, becomes difficult because of growing 
uncertainties of position, obstacles/traffic, and even the path. This is especially true at 
unfamiliar airports. These uncertainties can cause pilots to slow down until the uncertainty 
is reduced to a comfortable level, or cause them to continue at the same speed but with 
reduced confidence and safety margin. Also, dependence on voice communication as a 
sole source of path, or route, information can be unsafe due to the possibility of 
miscommunication or misunderstanding on the part of the pilot or the controller. 

The system flight tested in Atlanta is not meant to be a panacea for optimizing the safety and 
efficiency of surface operations in any weather condition. However, it is an attempt to 
show how new technologies can be used in the near term to reduce the uncertainties 
mentioned above for both controllers and pilots. As will be shown, these uncertainties are 
reduced by providing them with supplemental guidance and situational information. This 
information is provided in a natural manner such that it reinforces any cues that are 
available and replaces those that are not available. 


3 



The system employed and tested at ATL is based on several pieces of prior and related 
work. It is primarily based on “lessons-leamed” in flight simulation studies both at NASA- 
LaRC [5], and at NASA-ARC [6][7][8]; a flight test performed at the FAA Technical 
Center in 1995 [1]; and two draft requirements documents [9] [3], The latter describes 
operational requirements for an A-SMGCS. ICAO has sponsored the development of this 
document to describe a modular system consisting of several functions supporting safe, 
expeditious movement of aircraft and vehicles on the airport surface in all visibility 
conditions. Because the goals of A-SMGCS and the LVLASO research are so closely 
related, references to the A-SMGCS requirements will be made frequently in this 
document. The reader is encouraged to obtain a copy of [3]. 


II. SYSTEM DESCRIPTION 

The system flight tested at ATL can be considered using several abstractions. Functionally, 
it can be decomposed into surveillance, guidance, control, and routing functions (as has 
been done for A-SMGCS). Physically, it can be decomposed into the airborne and ground 
subsystems. Finally, temporally, it can be decomposed by operational phase (e.g. landing, 
roll-out, turn-off, taxi). Each of these abstractions will be used below to describe the 
conceptual system tested at ATL. 

Physically, the prototype surface operations system consisted of both ground and flight 
components that were integrated via three digital datalinks as well as the normal voice 
channels. The flight system provided the flight crew with enhanced guidance and 
situational awareness information through the use of a head-up display (HUD) and a head- 
down electronic airport map liquid-crystal display (LCD). These displays were integrated 
with onboard sensors and datalinks that provided the necessary input data as well as 
providing aircraft state data to the ground components. The displays were designed to 
function based on the phase of flight. During high-speed roll-out and runway exit, the 
Roll-Out Tum-Off (ROTO) display symbologies and functions were engaged. During taxi, 
the Taxiway Navigation and Situational Awareness (T-NASA) [6] display symbologies and 
functions were engaged. Regardless of the phase of flight (roll-out, turn-off, or taxi), the 
information presented on the displays was intended to supplement missing visual cues in 
low visibility situations or at night, and to reinforce any available visual cues that may have 
an uncertainty associated with them (e.g. sign directional arrows, traffic positions, path to 
follow, etc.). 

Similarly, ground components of the system provided the controller with supplemental 
information about traffic (e.g. position, identity, and intent), as well as a means for 
communicating with the flight crew over a digital link, in parallel with the normal voice 
channel. As with the flight crew, the information provided is meant to supplement missing 
visual cues and to reinforce uncertainties associated with whatever visual cues are available. 
Because of this supplemental information, it is expected that the amount of voice 
communication required would reduce (e.g. “Delta 625, say your position”). 

Functionally, the surveillance function is implemented on the ground (as described in 
Section II-B), with its outputs being provided to the guidance, control, and routing 
functions. The guidance fiinction is performed onboard by the vehicle/aircraft operator 
with inputs from the other functions. Control and routing functions are performed on the 
ground. Figure 1 shows how these functions relate and die data exchanged between them 
using the ATL architecture as a basis. 
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From [3], surveillance is defined as a function that captures identification and positional 
information on aircraft, vehicles, and objects within a specific area. Control is defined as a 
function that applies measures for preventing collisions, runway incursions, and ensuring 
safe, expeditious, and efficient movement. Routing is defined as the planning and 
assignment of a route to individual aircraft and vehicles to allow safe, expeditious and 
efficient movement from its current position to its intended position. Finally, guidance is 
defined as necessary advisory information provided in a continuous unambiguous reliable 
manner such that pilots and/or vehicle operators can steer their aircraft or vehicle along 
the assigned route while maintaining an appropriate velocity. 

A. FLIGHT SYSTEM 

As mentioned previously, the ATL testing was conducted using a Boeing 757-200 (B-757) 
research aircraft. Modifications to the flight deck included installation of the following 
three hardware devices (figure 2). 

HUD. A Head-Up Display device was mounted to be used from the left seat position. 

The HUD consisted of a projector mounted above and behind the pilot and a combiner 
glass mounted between the pilot’s eyepoint and the front left windscreen. This specific 
HUD was manufactured by Flight Dynamics, Inc. and was capable of projecting a 
holographic image onto the combiner based on a raster-type graphics input. The field of 
view was 30 degrees horizontal by 24 degrees vertical. The HUD was used to support the 
guidance function of the experimental system as described in Section II-C. 

Moving map LCD. A Liquid-Crystal Display device was mounted under the glare shield 
(left of center) and was used to render the moving map symbologies described in Section 
II-C. This LCD was manufactured by Rockwell International. The LCD was sunlight 
readable and provided 1024x768 pixel resolution. The viewing area was 8”x6” and had a 
65 degree horizontal viewing angle which allowed for viewing by both crew members. 

The LCD was driven by a raster-type graphics generator. 

PIP. A Pilot Input Device was mounted on the center aisle stand. The PID allowed the 
pilots to control the experimental displays (figure 3). The controls are described in Section 
II-C. 


Aft of the flight deck, pallet workstations contained the necessary on-board systems 
required for data acquisition/recording, power, flight management, audio/video 
recording/telemetry, datalink, and display generation. Figure 4 depicts the experimental 
flight system employed at ATL. Figure 5 depicts the locations of the equipment in the B- 
757 cabin. Hardware aft of the flight deck included: 

Silicon Graphics Indigo2 Extreme computer. The Indigo2 hosted the real-time software 
responsible for driving the map LCD portion of the system. This computer supported a 
SCRAMNET (described below) interface allowing it to communicate with the other display 
computer and the I/O subsystem. The software system design is described in [10]. 

Silicon Graphics Personal Iris fPI) computer . The PI hosted the real-time software 
responsible for driving the HUD portion of the system. This computer also supported a 
SCRAMNET interface allowing it to communicate with the Indigo2 and the I/O subsystem. 
The software system design is described in [10]. 
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Two VHF data radios and their supporting antennas . These identical radios were provided 
by Rockwell International and were set to operate in receive mode only. The first of the 
two was responsible for receiving DGPS corrections and forwarding them to the GPS 
receiver. The second radio was responsible for receiving traffic information and runway 
status information provided by the ground surveillance system. This data was then 
forwarded to the I/O processor for eventual display on the map LCD as described in 
Section II-C. The radios employed the Differentially encoded 8-Phase Key Shifting 
(D8PSK) modulation waveform and adhered to the RTCA standard protocol DO-217 [11]. 
The frequencies used during the Atlanta testing were 1 18.2 Mhz (for DGPS corrections) 
and 128.5 Mhz (for the traffic and runway status information). 

Extended Mode-S transponder unit and its supporting antenna . This unit contained a 
Mode-S radio, a GPS receiver, and an air datalink processor. The unit provided GPS 
position reports to the ground surveillance system. These reports adhered to Automatic 
Dependent Surveillance Broadcast (ADS-B) specifications. This unit also supported the 
bi-directional Controller-Pilot Datalink (CPDLC). CPDLC format adhered to the RTCA 
standard protocol DO-2 1 9 [ 1 2] . CPDLC messages were forwarded to the I/O processor 
for eventual display on the experimental displays in the flight deck as specified in Section 
II-C. 


I/O processor. This unit was responsible for reformatting data received by the 
experimental datalinks and providing it to the display computers. This processor also 
relayed data to be downlinked to the test controller at the ground site via the Mode-S 
transceiver. Finally, the processor integrated DGPS and Inertial Reference Unit (IRU) 
position data and provided it to the display computers. 

Blending of DGPS and IRU position data was critical to ensure a continuous position 
update on the two experimental displays. Without a blending function, the displays would 
“jump” at a 1 Hz rate and be distracting to the pilots. Also, this blending allowed for 
intermittent outages of the DGPS system and convergence to an accurate position when 
DGPS data was valid. A description of the algorithms employed for DGPS/IRU 
integration is given in [13]. 

As described in [13], the GPS position data from the Rockwell-Collins GPS receiver was 
input into the I/O processor and passed through a complimentary filter to produce GPS 
derived position. This filter was initialized to IRU velocity and acceleration values. Once 
the filter was initialized, each input of GPS data was saved and propagated forward using 
the velocity estimates. Each subsequent input was compared to the propagated value of the 
previous input, and rejected if it differed by more than a preset limit. If the data was valid 
and passed this limit test, it was differenced with the saved value of the filter position 
output corresponding to the age of the current GPS position. The difference vector was 
then input to the complimentary filter to correct the position estimate. The resulting 
position estimate was that of the center of gravity (CG) of the aircraft. With GPS data 
valid, DGPS data available and acceptable horizontal and vertical dilution of precision 
(HDOP and VDOP), the filter was checked for convergence. Once the average length of 
the difference vector remained below 30 feet for 15 seconds, a flag was set and the display 
system was permitted to use the derived position estimate. This flag remained set as long 
as valid data continued to be received. If this flag was not set, the experimental displays 
alerted the pilot(s) that the position report was not valid. This was done by flashing the text 
“DGPS INVALID” on both displays. 

In addition, there were other supporting systems onboard the aircraft that provided for 
instrumentation and intercomputer communications. These included: 
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SCRAMNET I/O network. The SCRAMNET network is a ring network that allows nodes 
to communicate via virtual shared memory blocks. SCRAMNET is the part of the basic 
research aircraft infrastructure that provides interfaces to the onboard Data Acquisition 
System (DAS) and the I/O processing system. For this testing, the four nodes on the 
SCRAMNET were the DAS, the I/O processor, the Indigo2, and the PI. 

Video recording system. Cameras and video recorders logged the following images: tail 
perspective, nose perspective, flight deck activity, scan-converted HUD display, scan- 
converted map display, and a view from near the pilot’s eyepoint. 

DAS. Digital data was stored and timestamped using the GPS time reference. This stored 
data is described in Section IV-A. 

Audio management system. Researchers were able to communicate from any seat position 
with (1) each other, (2) the flight deck, and (3) the ground. All audio received in the flight 
deck (by both the pilot and co-pilot) as well as voice transmissions to ground locations 
were recorded on the video recorders. 

Telemetry system. Two different video images were telemetered to the ground 
simultaneously. These two images were selectable from those available on the B-757 (see 
above) and were available for viewing by visitors and ground participants during the test 
runs. 

DGPS survey system. An independent GPS system was employed using an Ashtech Z-12 
receiver. This system recorded GPS data and, along with data stored at the ground site 
(see Section II-B), allowed for post-processing that resulted in nominal 5cm accurate 
position data. This data was used to evaluate the accuracy of the experimental real-time 
position determining system (Section TV-C). The two GPS receivers on the aircraft shared 
the same antenna. 

B. GROUND-BASED SYSTEM 

The ground subsystem, illustrated in figure 6, supported the surveillance, control, and 
routing functions. It also enabled the transfer of required information among the functions 
implemented on the ground and the B-757 research aircraft. 

The surveillance system consisted of four primary elements. Three are already part of the 
NAS and are used to provide controllers with supplemental traffic information in real-time 
such that safe separations can be maintained for surface movements. The fourth, AMDS, 
is an FAA research and development project that is primarily aimed at providing identity 
information to controllers. The four elements were integrated in an attempt to provide full 
coverage of the airport surface, to provide identity information to both pilots and 
controllers, and to collect data so that multipath mitigation algorithms can be developed. 
Requirements for a surveillance function are listed in [3]. 

The four elements of the surveillance function used for the ATL testing were: 

ASDE-3. The Airport Surface Detection Equipment captured position data (range and 
azimuth) for all aircraft or vehicles operating on the airport surface movement area at a 1 Hz 
rate. ASDE-3 is a radar operating in the Ku-band (15.7 - 16.2 Ghz). ASDE-3 does not 
require any equipage on aircraft or vehicles. It is capable of detecting targets with a cross 
section as small as three meters. Its range is specified to be 24,000 feet in all directions on 
the surface and up to 200’ above the surface. ASDE-3 and its associated display is 
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scheduled for deployment at 40 airports over the next four years. At the time of the testing, 
the ASDE-3 display was available and operational in the ATL tower cab although it was not 
fully commissioned. 

Although ASDE-3 is a high performance radar system, it does have certain limitations. 
ASDE-3 has a 500’ “cone-of-silence” area encircling the antenna. Targets in this area are 
not be visible by ASDE-3. In fact, at ATL, taxiway Dixie passes through this cone of 
silence (figure 7). Aircraft taxing on Dixie disappear from the ASDE-3 display while in 
this cone of silence. Further, there can be other coverage gaps with particular ASDE-3 
installations as it is a line-of-sight radar. For example, at ATL, the section of Echo running 
parallel to RWY 26L on the east end of the airport is not covered by ASDE-3 because of a 
“FLY DELTA” sign. Because of this issue, siting of the ASDE-3 is critical to ensure 
maximum coverage. Also, ASDE-3 is susceptible to multi-path reports. Energy pulses 
emanating from the radar can return after reflecting off several mediums along its path. 

This can result in a false target being reported and possibly displayed. Finally, ASDE-3 
does not report target identity information. 

It is because of these three issues (coverage, multi-path, and identification), that the other 
systems described below were integrated with ASDE-3 for this testing to hopefully ensure 
full coverage, minimal multi-paths, and identification which are required in [3]. 

ATTDS. The Airport Surface Target Identification System captured position and identity 
data for aircraft and ground vehicles equipped with ADS-B and Mode-S transponders. At 
ATL, ATTDS utilized five fixed receiver/transmitters (R/Ts) located on the north side of the 
airport (figure 7). These R/Ts performed a multilateration function on targets emanating a 
Mode-S beacon. The result of this multilateration function [14] was the position and 
identity of any equipped target with their Mode-S transponder operating. In addition, 
ATTDS captured the ADS-B transmissions emanating from the research aircraft at any or all 
of its five R/T sites. ADS-B transmissions include position and identity information [15], 
All position and identity data captured by ATTDS, in addition to data it acquired from the 
FPU (described below), was forwarded to the AMASS computer described below for 
“fusion” with the data from the other surveillance sensors. The ATTDS update rate was 
specified to be 1 Hz. The coverage area for the ATL ATTDS was specified to be only on 
the north side of ATL out to 500’ beyond the approach end of the runways and up to 500’ 
above the surface. 

AMASS. The Airport Movement Area Safety System, as configured at ATL, provided the 
following: (a) tracking of ASDE-3 targets; (b) data fusion of ATTDS target data (captured 
via multilateration or ADS-B) with ASDE-3 track data, and (c) safety logic to detect runway 
incursions and alert controllers and the test pilots. AMASS has been designed to visually 
and aurally prompt controllers to respond to situations which potentially compromise 
safety. AMASS is an add-on enhancement to the ASDE-3 radar that provides automatic 
alerts and warnings. AMASS is being designed to overlay information on the ASDE-3 
display; however, for this testing, an independent AMASS display was used. AMASS 
was designed to track up to 200 targets. 

For this testing, AMASS was also responsible for passing target information and runway 
status to a datalink manager (DM) for forwarding to the research aircraft. Runway status 
information consisted of hold lines drawn along the runway edge lines at locations where 
taxiways intersect the runway. These lines turned red (on both the controller and cockpit 
display) when high speed runway traffic (either landing or taking off) was within 30 
seconds of a specific intersection. These red lines turned off after the aircraft/vehicle 
passed the intersection. By knowing the runway status, pilots are less likely to enter the 
runway at an unsafe time. 
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FPU. A Flight Plan Unit provided a transparent interface to the ARTS-IIIA system 
database. This allowed ATIDS to extract the Mode-A code, the aircraft call sign, and the 
aircraft type from the database, in real-time, and associate this information with specific 
Mode-S transmissions received. All retrieved information was forwarded to AMASS for 
use by the fusion function. 

This resulting fused surveillance data was provided to both the test ground controller (i.e. 
via the controller interface described below) and to the B-757’s experimental moving map 
LCD (also described below). This enabled both the pilots of the B-757 and the controller 
to have the same “picture” of the airport surface traffic at any point in time. This is a 
requirement specified in [3], 

Supporting the guidance function (as well as the ADS-B portion of the surveillance 
function) of the system, a GPS ground station was implemented to provide differential 
corrections. This ground station operated independently of all other systems. It consisted 
of two GPS receivers and a VHF data radio. These three components were identical to 
those used onboard the research aircraft. One of the two GPS receivers was an Ashtech Z- 
12 that was responsible for storing data that could be used subsequent to the flights to 
obtain high accuracy “truth” data. The other was the Rockwell-Collins GPS receiver that 
operated in conjunction with the D8PSK radio transmitter to fully implement the RTCA 
DO-217 specification [11]. 

Between the surveillance system and the VHF data radio responsible for transmitting traffic 
information to the B-757, the DM was responsible for converting surveillance system data 
received from AMASS into the protocol required by the D8PSK transmitter. The DM was 
designed to be able to support multiple transmitter types simultaneously such that 
aircraft/vehicles with different receivers could acquire the traffic broadcast (if a reciprocal 
transmitter were connected to the DM). This enables alternate datalinks to be utilized. 

Supporting the routing and control functions of the system, a Controller Interface (Cl) 
allowed a test controller to mimic normal voice instructions in parallel, and then transmit 
these instructions digitally for display in the flight deck of the B-757. The Cl is described 
in more detail below. Two-way communications with the research aircraft were 
implemented using Mode-S Specific Services described in [16]. These adhered to the 
RTCA standard DO-219 [12]. 


C. DISPLAY SYMBOLOGIES 

1 . MOVING MAP LCD 

The map LCD onboard the B-757 provided both crew members with: 

• depiction of the airport layout; 

• depiction of current position and heading of the B-757; 

• depiction of current position of other traffic on the movement area; 

• display of ATC instructions including the taxi route; 

• display of runway status. 
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See figure 8 for a depiction of the map symbologies used at ATL. This map display 
format is part of the Taxiway Navigation and Situational Awareness (T-NASA) system 
that has undergone human factors testing in several simulation studies [6][7][8], In 
addition to the input data received from the datalinks and the DGPS/IRU system 
onboard, an accurate airport database was also required. This database was provided by 
Jeppesen and included all runway/taxiway edges and centerlines as well as hold-short 
lines. These were all required to be accurate to one foot (0.3m). 

The flight crew interacted with the electronic map through the PID (figure 3). The crew 
was able to select from six zoom levels, one of which was an overview of the entire 
airport. The airport overview zoom level was north up while all other zoom levels were 
track up. The crew also had the choice to display symbols for other traffic and, if traffic 
was displayed, show traffic identification labels, if desired. The capability also existed to 
scroll through the list of ATC instructions displayed in the lower portion of the map 
LCD. 

In addition to rendering the display, the moving map computer generated downlink 
messages that were relayed to the test controller at the ground site. For example, if the 
B-757 deviated from the route issued by ATC, a message was sent to the test controller 
alerting him of this deviation. Similarly, if the B-757 got back on its approved path, a 
“taxi route resolved” message was sent to the test controller. 

Along with the normal activities associated with operating the aircraft on the surface, the 
moving map LCD symbologies supported the guidance function of the system and was 
provided to remove guidance/navigation uncertainties that can become substantial in lower 
visibilities and at night. The display does this primarily by increasing the crew’s 
situational awareness. Inputs from the control, routing, and surveillance functions located 
on the ground are required. 

2 . ROLL-OUT, TURN-OFF, AND TAXI GUIDANCE HUD 

On the HUD, from final approach until the B-757 had safely exited the runway, the roll- 
out and turn-off (ROTO) symbologies were enabled. Specifically, while in the landing 
phase, the ROTO system displayed symbology similar to the symbology found on 
commercial HUD systems designed to provide landing guidance (figure 9). During the 
final approach, the pilot selected an exit using the PID. The exit chosen was displayed on 
the HUD in the box on the upper right-hand portion of the display. Along with the exit 
chosen, the box also listed the desired exit speed and the estimated distance from the 
projected touchdown point and the exit. 

Once the aircraft landed and the nose strut was compressed, the symbology transitioned 
from the in-flight symbology to the roll-out and turn-off guidance symbology (figures 10- 
1 1). While rolling out, the symbologies were presented to reinforce available visual cues 
that may be obscured due to visibility or darkness (i.e. runway edges and runway 
remaining markers) and to provide a deceleration profile to follow that will minimize 
runway occupancy time to the chosen exit. In particular, the velocity error bar on the left 
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wing of the velocity vector symbol (figure 10) and the projected exit speed listed on the 
left tells the pilot, at any point in time, whether he is moving too fast or too slow to make 
the exit at the desire speed. As the pilot gets closer to the exit, a football symbol and a 
goal line symbol become visible on the HUD. By adjusting his speed as he nears the exit 
such that the football symbol is as close as possible to the goal line, the pilot will be able 
to make the exit at the desired speed in minimum time. Again, these symbols are 
provided so that the pilot can maintain VMC roll-out turn-off times in IMC conditions or 
at night. After turning off of the runway the pilot decelerated the aircraft to taxi speed, or 
to a stop, depending on controller instructions received. 

As the taxi path was delivered by the test controller after exiting the runway, the 
symbology transitioned from the ROTO mode to the taxi mode. The taxi symbols are 
shown in figure 12 and included: 

• taxiway centerline markings along the approved taxi route; 

• edge cones along the approved taxi route; 

• indications of location and angle of turns along the approved taxi route; 

• ground speed; 

• previous, current, and next taxiway identifiers. 

All HUD symbols were displayed relative to the pilot’s eye reference point such that 
they overlaid the outside scene (e.g. the painted centerline stripe). The taxi HUD display 
format is part of the T-NASA system that has undergone human factors testing in several 
simulation studies [6][7][8]. 

Along with the normal activities associated with operating the aircraft on the surface, the 
HUD symbologies supported the guidance function of the system and was provided to 
remove guidance/navigation uncertainties that can become substantial in lower visibilities 
and at night. Inputs from the control and routing function located on the ground are 
required. 

3 . CONTROLLER INTERFACE 

During the testing, a ground controller located at a test site had access to a controller 
interface (Cl) in addition to his normal visual scans and voice communications (figure 13). 
The Cl provided: 

• electronic flight strips updated in real-time 

• continuous display of surface traffic positions and identification on an airport map 

• controller instruction capture and datalink to the B-757 via voice recognition or 
touchscreen 

• alerts of route deviation by the B-757 

• runway exit taken by the B-757 

Along with the normal voice communications, visual scans, and inputs from the 
surveillance function and the B-757 (via datalink), the Cl and the test controller 
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implemented the control and routing functions of the system. See [17] for a detailed 
description of the Cl. 

III. FLIGHT TEST OPERATIONS 

The deployment to ATL occurred in two separate sessions, July 31 to August 8, and 
August 18 to August 29. The first session included end-to-end operational checks of all 
flight test systems. Also, during this session, all flight tests using NASA test pilots as 
subjects were completed (see table 1). The second session consisted of flight tests, using 
commercial B-757 captains as subjects, and demonstrations for visitors from the aviation 
community. These demonstrations included a briefing, an opportunity to view a flight test 
from the ground site, and a tour of the B-757. 

All flight test runs defined in the test matrix (see table 1) were enacted with the following 
operational guideline: the operation shall follow, as close as possible, a routine flight operation 
from “gate-to-gate”. The only difference, operationally, would be the additional tools provided 
to both the test pilots and the test controller that would, hopefully, show the potential for 
improving the safety and efficiency of the surface operation. 

The flight deck crew of the B-757 was instructed to maintain radio contact as needed with the 
ATL ATC during the testing. Because the Cl was at the prototype stage, a test controller was 
used. This controller was located at the ground site (not in the tower cab) and monitored ATL 
ATC communications. Any verbal instructions designated for the B-757 were sent 
electronically, in parallel, to the aircraft via datalink and the voice recognition function of the 
CL These were then displayed on the two experimental flight deck displays as described in 
Section II-C. 

The crew were instructed to utilize the HUD and map LCD while maneuvering the B-757 on an 
as-needed basis. The HUD was to be used by the captain for supplemental guidance cues and 
enhanced situational awareness during landing, roll-out, turnoff, and taxi. The map LCD was 
to be used primarily by the first officer for situational awareness which could then be relayed to 
the captain if necessary. The captain could refer to the map LCD occasionally if desired. 

During test runs, the flight crew could manipulate the map LCD using the PID as desired 
(scroll through ATC messages, display traffic and labels, and change the field of view). 
Specific details on how to use the LVLASO display system were provided as part of each 
pilots’ training procedure prior to the flight experiment. 

A. PROCEDURE 

All flight test runs began in the ramp area located at the Fixed Base Operator (FBO) just north 
of runway 8L/26R (see figure 7). At initiation of a run, the B-757 was in position to begin 
taxi. At the start of the run, the responsible flight deck crew member called for taxi instructions 
from ATL ATC. Once ATC verbally relayed the taxi instructions to the B-757, the test 
controller repeated those instructions verbally into the voice recognition system and they were 
sent electronically to the B-757 for display on the experimental displays. The captain then 
taxied to the designated departure runway. After taking the runway, die B-757 would either 
(1) takeoff/circledand or (2) taxi down the runway depending on the test run (see table 1). 

Once clear of the runway, the B-757 verbally received a taxi instruction from ATC, Again, this 
taxi instruction was sent to the B-757 by the test controller in parallel via datalink. After the 
crew acknowledged receipt of the instruction, the captain taxied back to the FBO ramp area 
following the designated path and stop. While taxiing, the captain was instructed to taxi at a 
normal taxi rate or higher if he felt safety was not being compromised. 
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If a specific run included a landing, an ILS autoland was used to minimize the touchdown 
dispersion. On approach, the captain would set the “preferred exit” knob on the PID 
(figure 3) in a position appropriate for a specific exit. The ROTO system began operation 
at localizer capture, numerically displaying information about the selected runway exit and 
status of the ROTO system. After touchdown and the nose strut was compressed, the 
captain disengaged the autopilot and manually performed roll-out and turnoff procedure 
following the ROTO guidance symbology on the HUD. 

If a takeoff was not required for a specific test run, the B-757 taxied down the runway and 
exited as directed by ATC. The ROTO system was not part of these runs. These runs 
were performed to evaluate only the taxi guidance system onboard (T-NASA). 

B. TEST MATRIX 

The test matrix used for the ATL testing is shown in table 1 . These tests were defined to 
fulfill the goals of the testing while staying within the constraints placed on the deployment 
in terms of time and operational costs. The test variables were: 

• time of day (T): day or night; 

• HUD (H) on or off; 

• LCD (L) on or off; 

• left seat captain (Cpt); 

• landing (Land) required or taxi-only; 

• exit chosen; 

• southside or northside operation (O). 

Tests runs were done predominantly at night as this more closely represents a “low 
visibility” condition. The seven demonstration runs D1-D7 were identical so that every 
visitor would see the same operation. Test runs T1-T4 were training runs for the four 
commercial captains. 

A total of 53 test runs were successfully completed which resulted in 1378 minutes (almost 
23 hours) of audio, video, and digital data. The average run time was 26 minutes. Only 
two test runs had to be scrapped due to inadequate system performance or hardware 
failures. These are not listed in the matrix. Test runs 10-12, 19-21 , and 28-30 were 
omitted from the testing in order to increase the number of night runs. Test runs 37, 39, 
48, and 50 were omitted because they did not use either display and were in the matrix to 
be done by the NASA pilots only if time permitted as baseline runs. Test run 47 was not 
completed due to rain. 
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Table 1 . Test Matrix. 
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D1 

8/25 

R067 

19:19 

19:45 

D 

Y 

Y 

PB 

Y 

B3 (26R) 

N 

D2 

8/26 

R068 

15:22 

15:45 

D 

Y 

Y 

PB 

Y 

B3 (26R) 

N 

D3 

8/26 

R068 

19:26 

19:56 

D 

Y 

Y 

PB 

Y 

B3 (26R) 

N 

D4 

8/27 

R069 

15:23 

15:47 

D 

Y 

Y 

PB 

Y 

B3 (26R) 

N 

D5 

8/27 

R069 

18:46 

19:24 

D 

Y 

Y 

PB 

Y 

B3 (26R) 

N 

D6 

8/28 

R070 

15:39 

16:02 

D 

Y 

Y 

PB 

Y 

B3 (26R) 

N 

D7 

8/28 

R070 

19:07 

19:33 

D 

Y 

Y 

PB 

Y 

B3 (26R) 

N 


IV. RESULTS 

While the primary objective of this effort was to demonstrate the feasibility of the 
operational concept at a major airport facility, secondary objectives were to obtain data to 
(1) validate simulation findings and the operational concept, and (2) assess the performance 
of the individual technologies and the system as a whole. Meeting these objectives has 
been done using both qualitative (subjective) data and quantitative recorded digital data. 
Analysis of both data types is presented here. 

A. RECORDED DATA 

During the testing, data was taken in several formats. Test pilots and demonstration 
visitors completed questionnaires to obtain their expert, albeit subjective, opinion of the 
system as implemented in Atlanta. Also, audio/video recordings of all camera images and 
the experimental displays were made of each test run. This allowed for review of specific 
events, either noted while reviewing the questionnaire responses, or, while reviewing the 
recorded digital data. Finally, digital data was recorded onboard the B-757 and on five 
systems on the ground: the Cl, AMASS, ATIDS, the datalink manager, and the DGPS 
ground station. All digital data was timestamped using the GPS time reference. 

B. QUALITATIVE RESULTS 

Validating the feasibility of the system concept has been accomplished, in part, by 
obtaining qualitative questionnaire data and comments from test pilots during data collection 
runs and visitors during the demonstration runs. Comments were also obtained from Air 
Traffic Controllers that viewed the ATL testing. Finally, it should be noted that simply 
operating the system (including the B-757) through this series of tests in the environment 
of a busy international airport facility and not negatively impacting normal operations 
validates the operational concept to some degree. 

1 . PILOT COMMENTS 

All of the test pilots were favorably impressed with the LVLASO system demonstrated at 
ATL. In general, the pilots commented that the LVLASO technologies increased their 
situational awareness and had the potential to enhance safety on the airport surface. They 
commented that the information provided gave them greater confidence in their position on 
the airport, which in turn, allowed them to taxi with more certainty and with greater speed. 
The magenta taxi route displayed on the head-down electronic map was mentioned in 
particular as being useful in (1) reducing workload (not having to examine and interpret the 
taxi route on a paper map and also reducing communication with the first officer), (2) 
increasing taxi speed (with the ability to view the forward taxi route, particularly the long 
straight-aways), and (3) increasing situation awareness (route confirmation and taxiway 
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locations). The pilots commented that the display of other traffic was beneficial for 
situational awareness. Pilots mentioned that currently they can not view traffic behind 
them. With the electronic map, the crew was aware of the trailing traffic and was able to 
make conditions safer for the trailing aircraft by lowering thrust levels when accelerating. 
A detailed analysis of the questionnaire data solicited from the pilot test subjects will be 
documented in a separate report. 

2 . CONTROLLER COMMENTS 


Several air traffic controllers viewed the demonstration system at ATL. Some of these 
controllers were also consultants during the development phase. A significant part of their 
feedback was related to the electronic moving map display provided in the flight deck. The 
controllers suggested it would be very beneficial to have this display installed in the tower 
cab, oriented with respect to the tower such that the controller would have the same 
perspective as if looking out from the tower cab windows. This could greatly reduce the 
amount of pilot/controller communication (e.g. “say your position”), as well as confusion 
that results from this communication. Having this display in the tower could also eliminate 
the confusion over the identity and location of radar returns, since identification tags are 
available on the electronic map. The controllers also commented positively on using a 
fusion function to generate traffic positions instead of using returns from a single source. 

The controllers did have some concerns related to the controller interface (Cl) that was used 
for this testing. It was felt the correct approach was taken by using voice recognition. This 
would not place additional workload demands on a controller, as would 
keypad/touchscreen entry. The controllers were concerned about the reliability and 
robustness of the voice technology, however. In addition, the voice recognition would 
have to be able to respond to different voices, dialects, and non-standard phrases. A voice 
system would need to respond, for example, in emergency situations where stress and 
excitement would change the tone of a controllers voice. A detailed analysis of the 
performance of the Cl is given in [17]. 

3 . VISITOR COMMENTS 


Tables 2 and 3 summarize the questionnaire data received from the government and 
industry representatives who attended the demonstrations. The tabulated data is in 
response to the following statement: 

“These technologies would greatly benefit the National Airspace System (NAS) 
during airport surface operations particularly in low visibility.” 


Responses were solicited for both the capacity and safety perspectives. 87 of the 110 
attendees completed the brief questionnaire. While this data should not be used as the sole 
basis for justifying the proposed system, it is very encouraging and supports the premise of 
the research. Organizations represented included: 


NASA 

FAA 

Department of Transportation 
Avionics Manufacturers 


Air Traffic Control 
Airport Authorities 
Aircraft Manufacturers 
Airline Pilots Association 


Airlines 


Media 


ICAO and RTCA 
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Table 2. Improving Capacity Responses. 


Technologies 

SD 

(1) 

D 

(2) 

N 

(3) 

A 

(4) 

SA 

(5) 

Ave 

Moving Map LCD 

1 

1 

3 




HUD Taxi Guidance 

0 

0 

7 

42 

38 

4.35 

HUD Roll-Out Turn-Off Guidance 

0 

0 

6 

43 

38 

4.37 

DGPS/IRU Aircraft Position Determination 

0 

1 

11 

41 

34 

4.24 

Datalink Of Traffic 

0 

1 

15 

45 

26 

4.10 

Datalink Of Runway Status 

0 

2 

15 

44 

26 

4.08 

Controller-Pilot Datalink For Surface Operations 

0 

2 

13 

44 

28 

4.13 

Aircraft Tagging On Controller Display 


6 

19 

40 

22 

3.90 

Automatic Dependent Surveillance - Broadcast 

0 

1 

21 

40 

25 

4.02 

Surveillance Sensor Fusion 

0 

1 

29 

34 

23 

3.91 

Controller Interface With Flight Strips 

0 

4 

29 

38 

16 

3.76 

Integration Of Above Technologies And The 

0 

1 

1 

45 

40 

4.43 

Overall Operational Concept 








Table 3. Improving Safety Responses. 


Technologies 

SD 

(1) 

D 

(2) 

N 

(3) 

A 

(4) 

SA 

(5) 

Ave 

Moving Map LCD 

0 

1 

2 

33 

51 

4.54 

HUD Taxi Guidance 

0 

0 

5 

42 

40 

4.40 

HUD Roll-Out Turn-Off Guidance 

0 

2 

10 

43 

32 

4.21 

DGPS/INS Aircraft Position Determination 

0 

1 

5 

34 

47 

4.46 

Datalink Of Traffic 

0 

0 

10 

37 

40 

4.34 

Datalink Of Runway Status 

0 

0 

4 

40 

43 

4.45 

Controller-Pilot Datalink For Surface Operations 

0 

1 

10 

47 

29 

4.20 

Aircraft Tagging On Controller Display 


1 

11 

42 

33 

4.23 

Automatic Dependent Surveillance - Broadcast 

0 

1 

16 

36 

34 

4.18 

Surveillance Sensor Fusion 

0 

0 

22 

36 

29 

4.08 

Controller Interface With Flight Strips 

0 

2 

30 

39 

16 

3.79 

Integration Of Above Technologies And The 

0 

1 

1 

42 

43 

4.46 

Overall Operational Concept 








1 

SD 

Strongly Disagree 

2 

D 

Disagree 

3 

N 

No Opinion 

4 

A 

Agree 

5 

SA 

Strongly Agree 


Ave 

Average Score 


As shown in Tables 2 and 3, the vast majority of the visitors either agreed or strongly 
agreed that these technologies would help improve capacity and safety on the airport 
surface. This qualitative questionnaire data, while not conclusive, is very encouraging and 
suggests that the premise of the research does have merit and warrants further study. 
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c. 


QUANTITATIVE RESULTS 


In order to assess the system performance as well as the performance of individual 
technologies, metrics have been defined which can be quantified using recorded data. 
Assessment of the prototype system includes evaluation of each major subsystem: 

• flight deck displays; 

• datalinks; 

• onboard position determination system; 

• surveillance system; 

• controller interface. 

Because several reports are being written concurrently documenting individual 
contributions, this document will report only on those metrics that have the most impact on 
overall system performance. Detailed information on each subsystem can be obtained as 
subsequent reports are published by the respective organizations. In addition, a large part 
of the assessment of the displays involves assessment of the effectiveness of the man- 
machine interface during the testing. This analysis is being done by members of the team 
from Ames Research Center and will be reported in a separate document. 

1 . FLIGHT DECK DISPLAY PERFORMANCE 

Display performance is primarily characterized by the update rates and the latencies 
associated with the symbologies being presented to the crew. Failure rates of displays are 
also important, however, for this testing, there were no failures of the display system. 

This does not imply that the displays had a failure rate of zero, simply that they did not fail 
over the relatively short period of testing in Atlanta. For example, the advertised failure 
rate of the HUD was 8000 hours, while the total duration of all flight tests at ATL was just 
over 23 hours. 

With the exception of the taxi route (which was displayed as it arrived), all HUD 
symbologies were updated at 10-15 hertz depending on the amount of symbologies being 

presented at any point in time during the flight. Position (coming from the DGPS/IRU 

blending function) and heading information presented on the map LCD were updated at 25 
hertz. Traffic and runway status data were updated at one hertz. Controller instructions 
arriving via the CPDLC datalink were updated on the displays as they arrived. 

Latency is the delay associated with processing information. For this flight testing, the 
only significant latency observed was that associated with the traffic data. The ground- 
based surveillance system took as long as one second to “scan” the airfield for traffic before 
it forwarded the entire scan of data to the research aircraft. Onboard, the I/O processor 
waited until it had received a full scan of traffic before it forwarded it to the display system. 
This took up to one additional second if traffic conditions were heavy and the datalink 
became loaded. Thus, the latency for the display of traffic data on the map LCD varied 
between one and two seconds depending on the number of targets on the airport surface. 
For the largest number of targets that occurred during the testing (47), the latency was ~2 
seconds. Alternate means of data processing could improve this latency (e.g. draw every 
target report as it is received). Latencies for drawing all other symbologies were near zero 
(i.e. not measurable). 
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Although [3] recommends less than one second latency for traffic information updates in 
extremely low visibilities (<75m), as much as two seconds latency may be adequate for 
most, if not all, cases. For taxi (<40 knots), this represents a worst-case of 40m of 
translation in two seconds. If the display of traffic is used solely to improve situational 
awareness, in-trail separations during taxi can still be maintained visually with occasional 
reference to the traffic updates on the display for projections of traffic intent. For runway 
activity, the higher speeds (e.g. 150 knots) will yield much larger translations during a two 
second delay (e.g. 135m). For this reason, pilots must be briefed on this maximum 
latency, if it is to be tolerated. Also, alternate means of alerting pilots of high-speed 
runway traffic, like the runway status symbols implemented in this testing, should be 
considered. 

2 . DATALINK SYSTEM PERFORMANCE 

Datalink performance can be quantified using several metrics. These include coverage, 
signal strength, and availability. Coverage is defined here to be the surface area over which 
the datalink performed correctly (as specified). Signal strength is the amount of signal 
detected at the receiver at a specific range from the transmitter. Availability will be defined 
as the fraction of time that the datalink was operating correctly (as specified) during any 
given time interval. 

The four datalinks utilized at ATL were the VHF datalink for DGPS corrections (VHFd), 
the VHF datalink for traffic data (VHFt), the CPDLC datalink, and the ADS-B datalink. 

VHF Datalink Performance fboth VHFd and VHFti 

Datalink performance was characterized for the VHF datalinks aboard the B-757 by 
recording DGPS position and datalink message status outputs from the GPS receiver; and 
also by recording received signal strength outputs based on internal receiver Automatic 
Gain Control (AGC) information from the VHF DGPS datalink receiver. Three states of 
message status were recorded; 1) no message received, 2) message received but CRC 
failed, and 3) message received and CRC passed successfully indicating a correctly 
received message. Because the two VHF datalink applications (corrections and traffic) 
utilized identical hardware and an identical protocol (DO-217), an independent evaluation of 
the traffic datalink will not be presented here. The only difference was the specific 
application data placed in the messages. 

Figure 14 is a representative VHF DGPS datalink performance plot depicting the path on 
the surface traversed by the B-757 during a particular test on the northside of ATL. Figure 
15 is a similar plot for a test on the southside. Larger squares indicate that received 
messages were garbled (failed CRC) or not received. 

Figures 14 and 15 show that coverage was excellent for the VHF datalinks. Figure 16 
shows flight data including times while the B-757 was in the pattern. Figure 16 is 
representative of the performance observed while flying in the pattern at ATL. In general, 
good signal strengths (between -67 and -77 dBm) were measured on the surface and out to 
about 10 nautical miles (nmi). The only area of concern was the northwest comer of the 
terminal area, beyond 5 nmi range, where it was evident that signal blockage due to 
additional building structure atop the Renaissance Hotel played a significant role. Those 
few messages that were lost while the B-757 was on the airport surface (figures 14 and 15) 
can be attributed to multipath, probably resulting from the large hangars on the southeast 
comer of the north runway area and the concourse buildings. Table 4 lists the performance 
observed at ATL for flight number R062 through R066. Of the events where a message 
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was lost, only once were three consecutive messages lost. There were three events where 
two consecutive messages were lost. Never were more than three consecutive messages 
were lost. 

Table 4. VHF D8PSK Datalink Performance (R062-R066). 


Type 

Trans 

mitted 

Receiv 

ed 

% 

Garbled 

Lost 

Taxi 

15792 

15765 

99.83 

15 

12 

Flight 

26412 

26350 

99.77 

53 

9 

Total 

42204 

42115 

99.79 

68 
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The effective bandwidth utilized for the VHF datalinks can also be quantified. Because the 
traffic datalink requires the most bandwidth and is dependent on current traffic conditions, 
it can have the most impact on system performance. For these tests, the maximum number 
of targets seen by the surveillance system at any time was 47. This translated to 6256 bits 
of data to be transmitted in one second using the message format defined for these tests. 
This represents only 20% of the specified 31500 bits per second budget. 

Bandwidth utilized for the other three applications by the other datalinks is very low. For 
instance, the DGPS corrections messages used less than one third of one of the eight 
TDMA slots as per DO-217 Til] and ARINC 743 A [18]. Only 112 + 48n bits per second 
(where n is the number of satellites) of the 31500 bits per second bandwidth budget were 
utilized for DGPS corrections. Even for 12 satellites, this is only 688 bits per second. 
Similarly, the ADS-B and CPDLC applications used a very low percentage of the available 
bandwidth budget for this test. Had other equipped aircraft/vehicles been involved, this u 
may have become an issue for the link. [19] discusses issues related to the bandwidth of 
the Mode-S link. 

CPDLC Datalink Performance 


Because controller-pilot datalink messages were very short and infrequent, the primary 
metric of interest is the percentage of messages that were lost in transmission. Table 5 
summarizes the performance observed for five representative flight days (R062-R066). 

Table 5. CPDLC Datalink Performance. 


Flight No. 

Uplinks 

Sent 

Rcvd 

Downlinks 

Sent 

Rcvd 

R062 

93 

84 

103 

97 

R063 

82 

76 

97 

92 

R064 

79 

77 

96 

96 

R065 

68 

62 

75 

72 

R066 

53 

44 

57 

55 

Total 

375 

343 

428 

412 


Overall, the probability of correct reception for the CPDLC uplink was 92%. The 
probability of correct reception for the CPDLC downlink was 97%. Both of these numbers 
represent very good performance particularly considering the fact that two modems were 
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used to transmit this data between two ground sites (the tower and the hotel) as well as 
utilizing the Mode-S link with the aircraft. Finally, the delay, seen by the test controller, 
between sending an instruction and receiving a “ROGER” from the B-757 was measured to 
a mean of one second. Further specifics on the performance of the CPDLC link and the Cl 
used at ATL are given in [17]. 

ADS-B Datalink Performance 

This specific issue is of paramount importance to the aviation community as the current 
NAS plans suggest possible world-wide equipage with ADS-B capability in the future 
[15]. As with any new technology with such a scope, there are a multitude of metrics that 
must be quantified to ensure safe robust use in the NAS. Examples are coverage, capacity, 
update rate, and transmission waveform and frequency. With only one ADS-B participant 
for these tests at ATL, most of these issues could not be addressed. However, Rannoch 
Corporation has been tasked with assessing the ADS-B performance observed at ATL. 

This will be published in a separate report. One metric that has been quantified is the error- 
free ADS-B reception percentage for individual test runs. Table 6 shows the ADS-B 
reception percentages for representative runs while the B-757 was operating on the airport 
surface at ATL. 

Table 6. Error-free ADS-B Reception. 


Run 

EFSR 

EXSR 

% 

07 

2579 

2690 

95.9 

08 

1563 

1644 

95.1 

09 

2603 

2696 

96.6 

15 

2401 

2479 

96.9 

16 

1995 

2074 

96.2 

18 

1667 

1710 

97.5 

24 

3209 

3470 

92.5 

25 

1694 

1742 

97.2 

26 

2350 

2436 

96.5 

27 

1634 

1673 

97.7 

35 

1387 

1417 

97.9 

36 

1030 

1059 

97.3 

40n 

3135 

3238 

96.8 

43 

1495 

1540 

97.1 

45 

3278 

3343 

98.1 

46 

1864 

2042 

91.3 

49 

1907 

1955 

97.5 

51 

2355 

2412 

97.6 

53 

2333 

2405 

97.0 

54 

2447 

2496 

98.0 

55 

1195 

1226 

97.5 

56 

1341 

1384 

96.9 

58 

3028 

3099 

97.7 

Total 

51050 

52870 

96.6 


EXSR is the expected squitters to be received (i.e. two per second) and EFSR is the error- 
free squitters received by at least one of the five ground-based R/Ts at ATL. 
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3. 


ON-BOARD POSITION DETERMINATION PERFORMANCE 


Determining the position of the research aircraft onboard and in real-time was accomplished 
using inputs from the DGPS system and the Inertial Reference Unit (IRU) as described in 
Section II- A. Several metrics can be defined related to the accuracy of the position reports. 
These include the horizontal root-mean-square (RMS) error, the cross-track error (Xtrk), 
and the along-track error (Atrk). In addition, horizontal and vertical dilution of precision 
(HDOP and VDOP) values are produced by the GPS receiver. 

These metrics are depicted in figures 17-20 for a representative day of testing at ATL. Only 
surface data is used and as such the RMS error is only calculated for the horizontal plane 
(i.e. altitude errors are not included). Table 7 summarizes the DGPS performance. RMS, 
Xtrk, and Atrk statistics are given in meters. Flight numbers correspond to flight days. 
Each flight number constitutes several test runs (see Table 1). 

Table 7. DGPS Performance. 


Flight 

No. 

Points 

(sec) 

RMS 

Mean 

RMS 

Std 

95% 

Xtrk 

Mean 

Xtrk 

Std 

Atrk 

Mean 

Atrk 

Std 

R056 

3970 

0.88 

0.45 

1.64 

-0.14 

0.62 

0.21 

0.74 

R057 

3433 

0.97 

0.52 

1.93 

-0.25 

0.69 

0.15 

0.80 

R058 

6218 

0.76 

0.50 

1.62 

-0.12 

0.55 

0.06 

0.71 

R059 

2588 

0.70 

0.42 

1.43 

-0.04 

0.50 

0.10 

0.63 

R062 

4795 

0.77 

0.64 

1.68 

0.08 

0.69 

0.08 

0.71 

R063 

7312 

0.72 

0.43 

1.46 

-0.01 

0.54 

-0.01 

0.65 

R064 

6614 

0.73 

0.45 

1.61 

0.05 

0.54 

0.04 

0.66 

R065 

4060 

0.79 

0.72 

1.69 

0.01 

0.55 

0.08 

0.91 

R066 

2725 

0.84 

0.47 

1.78 

-0.08 

0.69 

0.04 

0.66 

Total 

41715 

0.78 

0.52 

1.63 

-0.04 

0.60 

0.07 

0.72 


Finally, the DGPS/IRU solution was produced and available for 41379 of the total 41715 
seconds listed above. This constitutes 99.2% availability of a valid position report. For 
the entire duration of the testing at ATL, the mean HDOP was 1 .51 (0.19 std) while the 
mean VDOP was -2.20 (0.34 std). 

It is important to note that the real-time position observed by the flight crew on the 
experimental displays (both the HUD and the LCD) was derived from the DGPS sensor 
data (presented in table 7) and data coming from the IRU. The result of this “blending” 
function was a robust, continuous update that removed much of the noisy behavior of the 
raw DGPS updates while converging to an accurate position. It is recommended that some 
form of DGPS/IRU blending (like the one implemented at ATL) be performed to avoid 
“jumpy”, erratic, unreliable updates of position being presented to pilots on a 
guidance/navigation display. This implementation was also able to tolerate intermittent 
outages of DGPS which are likely to occur in the airport environment. 
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4 . 


SURVEILLANCE SYSTEM PERFORMANCE 


The majority of the surveillance data recorded at ATL will be analyzed and documented in a 
separate report to be published by members of the team from the FA A. This includes data 
from the three surveillance sensors employed (ASDE-3, ATIDS multilateration, and ADS- 
B) as well as the sensor fusion results. Several metric s are being quantified including 
dropouts (and where they occurred), multi-paths targets (and where they occurred), 
accuracy (of the three surveillance sensors individually), latency, and capacity. 

5 . CONTROLLER INTERFACE SYSTEM PERFORMANCE 

[17] describes the performance measured for the experimental controller interface 
implemented at ATL. The primary metrics of interest are those associated with the voice 
recognition component of the Cl. Overall, the voice recognition system correctly captured 
the spoken instructions 97% of the time while testing at ATL. Verbal instructions that were 
not captured correctly were either due to (1) not recognizing the specific language used, or 
(2) recognizing an instruction incorrectly. 

Examples of the above are: 

Verbal Instruction 

‘Taxi to Runway Two Six Left Via Dixie.” 

“Taxi to Runway Two Six Left Via Dixie.” 


Result of Voice Recognition 

“NOT RECOGNIZED - SAY AGAIN” 

“Taxi to Runway Two Six Left Via Alpha.” 


V. CONCLUSIONS 


This activity has demonstrated the potential for using technology and a holistic systems 
approach for improving the safety and efficiency of airport surface operations. By 
providing supplemental guidance and situational awareness information to both pilots and 
controllers, safety margins can increase as there is more confidence in the understanding of 
the current state of the airport surface. In poor visibility, at night, or at unfamiliar airports, 
this supplemental information becomes critical, particularly if VMC flow rates are expected 
to be maintained safely. Although this system was not demonstrated in low visibility at 
ATL, the questionnaire responses received from the test subjects and the visitors from the 
aviation community (Section IV-A) clearly support this conclusion. 

Further, this demonstration revealed that there can be a near-term implementation of many 
of the demonstrated technologies. ASDE-3 and AMASS are part of the NAS. DGPS has 
been standardized for Special Category I (SCAT-I) landings [11] and is the primary sensor 
for the Wide-Area Augmentation System (WAAS) and the Local Area Augmentation 
System (LAAS). HUDs are onboard many commercial jets providing takeoff and landing 
guidance to flight crews. In fact, the unit used onboard the B-757 for these trials was 
manufactured for commercial use onboard a Saab 2000 aircraft. Finally, thousands of 
Mode-S transponder units like the one used in this test are onboard commercial aircraft 
today. 

Keep in mind that the primary goal of this activity (other than system demonstration) was to 
validate the operational concept. As described earlier, this concept is to provide pilots and 
controllers with (1) continuous awareness of position on the airport surface, (2) continuous 
awareness of aircraft/obstacle positions, and (3) continuous awareness of path/route to 
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follow from current position to the destination. This implementation assumes a ground- 
based surveillance system at the airport, an accurate position sensor onboard, and a 
ground-based path/route generation system. This operational system was demonstrated 
and shown to be valid at ATL. It should be noted, that specific technologies are not being 
advocated, but were merely used as a means to this end. Specific technologies were 
evaluated and may be recommended as the solution as the research continues. 

For example, the active matrix LCD used onboard the B-757 to support the moving map 
application is not recommended for use on current commercial jets. Although, the LCD 
performed very well and has several attractive features (e.g. sunlight readable, high 
resolution), it could not readily be retro-fitted into most aircraft. It is envisioned that the 
map function would reside on the Navigation Display (ND) available to both crew members 
or on a multi-function display (MFD) head. This is the planned approach for the 
subsequent simulation and flight test activities. 

A. A-SMGCS COMPLIANCE 

At ATL, the guidance function was primarily supported by the HUD/LCD, the DGPS/IRU 
blending function, and the CPDLC datalink that provided the route to the displays. Of 
course, the centerline lights/paint and signage were used as the primary guidance/navigation 
inputs. This implementation, as demonstrated, met all of the operational requirements for 
guidance listed in [3]. Many of the performance requirements suggested in [3] were also 
met (e.g. 0.78m RMS accuracy for the DGPS/IRU position sensor). The most stringent 
requirement for position error mentioned in [3] is for the stand area (0.5m). This accuracy 
was not achieved at ATL. Subsequent work must be done to determine the appropriateness 
of this requirement and if necessary, a solution that meets it. 

The routing function demonstrated at ATL also met nearly all of the operational requirement 
listed in [3]. The routing function was implemented at ATL using a test controller, the 
voice recognition Cl, and the CPDLC datalink. The requirement to generate minimum 
distance routes was not demonstrated. Also, because the B-757 was the only equipped 
vehicle, demonstrating providing the route to all aircraft was not possible. Some of the 
routing performance requirements listed in [3] were demonstrated (e.g. less than one 
second to transmit route from ATC to aircraft). Subsequent work must investigate an 
appropriate datalink that can support CPDLC to all vehicles and an advisory tool for 
controllers that generates a minimum distance route. 

Many of the operational requirements for the control function listed in [3] were not 
explicitly demonstrated at ATL as they are aimed at providing alerts of inappropriate 
intrusions to controllers. The B-757, while at ATL, did not perform any of these 
intrusions; although, the B-757 was capable of generating alerts of route deviation and 
providing this to ground control. This is a requirement of [3], ~ 

Finally, the operational requirements for the surveillance function listed in [3] were 
demonstrated. Performance requirements for coverage, accuracy, update rate, and latency 
were demonstrated. However, integrity, continuity, and availability performance did not 
appear to be adequate, primarily due to intermittent multi-path reports and occasional 
failures of the fusion function which resulted in split reports for a single target. 

Subsequent work will address both of these phenomena and how they effect the 
performance metrics mentioned above. 
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B. OBSERVATIONS 


In order for this operational concept to meet its full potential, there are technical challenges 
that still must be overcome (e.g. multi-path mitigation, robust voice recognition, moving 
map retrofit, software certification, crew roles and procedures, guidance-to-the-gate). 

These will be addressed as the research continues. Partial implementations of this system 
can be implemented in the near-term to provide many benefits with only minimal additional 
technical work. In terms of operations, the intent is to design a system that has minimal 
impact on normal operations and procedures. The aids are provided to pilots and 
controllers in such a way as to not increase workload and to be used only as needed. 

The research program deliverable is a set of operational and technical requirements for a 
system that safely enables VMC capacities at airports in IMC conditions down to Category 
111B. Through this flight test activity, a significant step has been taken toward providing 
that deliverable to the aviation community. 
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Figure 1. System Function Dependencies. 
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Figure 2. Flight Deck Layout. 



Figure 3. Pilot Input Device. 
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Figure 4. Flight System. 


LAVATORY 



■ VIDEO 1 


CREW 

CHIEF/Indigo 

Computer 


U~uW 
Q /D R 


m. 


VIDEO 2 


AFT 

GALLEY 


iB dUqU n 

inqaiq a i 


- POWER / 



VIDEO 3 
DAS 1 


■ SCRAMNet+ 


TOP VIEW 


I 


LAVATORY 



ItalirauruRTil 


wzzzzzzzl a _ 


FS1 
200 

. WING BOX, FUEL TANK, & MAIN 
GEAR WELL COMPARTMENT 


SIDE VIEW (LEFT) 



Telemetry 

Equipment 

Tray 
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Figure 8. Moving Map LCD Symbologies. 
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Figure 13. Controller Interface Display. 
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Figure 17. DGPS Performance, R0S9 (18:45-20:00) 
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Figure 18. DGPS Performance, R059 (18:45-20:00) 
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Figure 19. DGPS Performance, R059 (18:45-20:00) 
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Figure 20. DGPS Performance, R065 
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